home *** CD-ROM | disk | FTP | other *** search
/ Archive Magazine CD 1995 / Archive Magazine CD 1995.iso / discs / prog_disc / volume_2 / issue_04 / basiccomp / readme next >
Encoding:
Text File  |  1995-06-22  |  6.7 KB  |  118 lines
  1.      
  2.      ----------------------------------------------------------------------
  3.      
  4.                 ****     ***         ****       ****     ***  ***
  5.               ********   ***        ******    ********   ***  ***
  6.               ***   **   ***       ***  ***   ***   **   ***  ***
  7.                ****      ***       ********    ****      ********
  8.                  ****    ***       ********      ****    ********
  9.               **   ***   ***       ***  ***   **   ***   ***  ***
  10.               ********   *******   ***  ***   ********   ***  ***
  11.                 ****     *******   ***  ***     ****     ***  ***
  12.      
  13.                       A utility to compress BASIC programs
  14.      
  15.      ----------------------------------------------------------------------
  16.      
  17.      Now  that we have lots of memory for BASIC programs (don't we?), there
  18.      is no excuse, as there once was, for being mean with REMs, blank lines
  19.      and the length of variable names. These can make  all  the  difference
  20.      between a program that is easy to follow and to modify and one that is
  21.      totally  impenetrable.  Yet even magazines such as this sometimes nod;
  22.      though the editorial space saved by an unadorned listing can  be  more
  23.      than offset by a long textual explanation. 
  24.      
  25.      Yet  there  is  still value in compressing BASIC programs which may be
  26.      considerable if you wish to store utilities in EPROM or battery-backed
  27.      RAM on a ROM podule. This program, for  example,  can  be  reduced  in
  28.      length by more than 50%; 25-30% is however more typical.
  29.      
  30.      Besides,  a  compressed  program runs appreciably faster. A run of the
  31.      full version of SLASH on an example 30k  program  including  assembler
  32.      took  54  seconds  compared with 41 seconds using the fully compressed
  33.      version. And a compressed version of the variant of  SLASH  (SLASHINTG
  34.      on  the  disc)  which  uses  the  resident integers in place of normal
  35.      integers runs even faster; 35 seconds for the example. Of  course,  it
  36.      is  almost  impossible  to read the code but this may be a useful ploy
  37.      sometimes to 'protect' your ideas!
  38.      
  39.      This program, SLASH, allows you to remove any  or  all  of:  redundant
  40.      leading spaces and colons, REMs, and empty lines, in that order. Using
  41.      the  BASIC  Editor  to do this is extremely tedious and in any case it
  42.      can  be  hazardous  because  it  is  only  too  easy  accidentally  to
  43.      concatenate lines which damage the logic flow or even to delete a line
  44.      completely. Thus comprehensive testing AFTER compression is essential:
  45.      a great disincentive to doing it!
  46.      
  47.      Some  compression  programs  go further than this one; eg, they remove
  48.      spaces within lines and  concatenate  them.  This  does  save  further
  49.      space,  though  not  all  that much, but the line analysis needs to be
  50.      very  much  more  complex  than  in  this  program  to  avoid  illegal
  51.      concatenation (such as in extended IF...THEN...ELSE and CASE...OF) and
  52.      to  preserve spaces in explicit strings. Thus such programs tend to be
  53.      very slow unless they are in machine code.
  54.      
  55.      In SLASH you also have the option to enter a  range  of  line  numbers
  56.      which  will  NOT be processed, whatever the other options set. This is
  57.      useful if you want to preserve a heading, a group of explanatory lines
  58.      or a fully commented procedure.  You  will  see  these  lines  flagged
  59.      '[Skip]'  during  processing. The compressed program has a line added:
  60.      '0REM>new-path/file-name' so the system can refer to it properly (this
  61.      is not done if you select no changes!). If the old program already had
  62.      a line 0 you may find another in the new program, but you  can  easily
  63.      re-number  it.   The  % compression and time taken are reported at the
  64.      end. 
  65.      
  66.      SLASH deals with assembler remarks (introduced by ';' or '\'  as  well
  67.      as  'REM') but unfortunately this needs detection of entry to and exit
  68.      from the assembler which is made difficult by the use of '['  and  ']'
  69.      within  the assembler syntax and slows processing. Assembler lines are
  70.      flagged whilst they are being processed. The algorithm will  NOT  deal
  71.      correctly with remarks EMBEDDED in the assembler; it assumes that they
  72.      are always at the ends of lines, or on separate ones, like REMs.
  73.       
  74.      The program will not allow you to attempt to compress a directory or a
  75.      file whose 'type' is not BASIC, or to save to an existing locked file.
  76.      It  will warn you of overwriting the original or any existing UNLOCKED
  77.      file, or if there is no disc in the nominated drive. In each case  you
  78.      can  go  back  and  correct  the input. The compressed file can be put
  79.      straight into the RFS by entering 'RFS:$.Library.<filename>'  for  the
  80.      output  file.  ESCAPE  ends  the program at any point without damaging
  81.      files.
  82.      
  83.      The program itself is 'linear' apart from the central double loop,  so
  84.      subroutines  and  procedures  have not been used, just 3 functions. It
  85.      uses flags extensively to control  execution  flow  depending  on  the
  86.      options chosen.
  87.      
  88.      The  new  file  is  overlayed on top of the original in the byte array
  89.      'filespace',  line  by  line.  The  original  file  is   loaded   into
  90.      'filespace'  offset  sufficiently for the title line (up to one screen
  91.      line long) to be inserted into  the  new  file.  There  are  two  file
  92.      pointers  into  'filespace'  keeping  note  of  the  beginning  of the
  93.      unprocessed old file and of the end of the accumulating new one. There
  94.      are also two line  pointers;  one  into  the  section  of  'filespace'
  95.      holding  the current old line, and the other into 'linespace' in which
  96.      the replacement line is  being  constructed.  Note  that  BASIC  lines
  97.      actually   BEGIN  with  &D,  but  here  the  &D's  are  used  as  line
  98.      TERMINATORS. 
  99.      
  100.      One  other  programming  feature  of  interest  is  the  use  of  'SYS
  101.      "OS_File",n'   calls  to  allow  economical  but  comprehensive  error
  102.      trapping in the file nomination routines. Note how object  type,  file
  103.      type  and access status are extracted (lines 570-600 and 670-720), and
  104.      how file type is set during saving  (line  2100).  The  SYS  "OS_file"
  105.      calls  mostly  require  a  POINTER in Register 1 to a path or filename
  106.      anywhere in memory. In BASIC  a  string  variable  name  IS  simply  a
  107.      pointer,  so the 'name$' is all that need be given to the SYS call, as
  108.      exemplified here.
  109.      
  110.      
  111.      
  112.      ----------------------------------------------------------------------
  113.      
  114.      Brian Carroll                                            December 1988
  115.      
  116.      ----------------------------------------------------------------------
  117.      
  118.